So You Want to Build an Automated Scheduling System

The BBN scheduling group contracts with both government and industry to perform research and development for geneticalgorithm-based scheduling. We have developed custom real-world automated scheduling systems for different clients. Here, I relate some of the insight gained from our experience organized into a few broad categories. 1 SELLING THE PROJECT Clearly, one of the critical parts of building an automated scheduling systems is securing the commitment of sufficient money and resources to accomplish the job. Selling such a project within an organization requires a champion (or champions) inside the organization, someone who will put their influence and credibility behind the effort. As an outside contractor, one of our toughest jobs is trying to find such a champion. If you are an insider in the organization, you are at a big advantage because you can be that champion or know who else to approach. There is likely to be a lot of resistance to the proposed project because there is a lot at stake. Scheduling is often at the heart of the business process, and changing how the scheduling is done likely means an overhaul of this process. The results can affect not only the organization’s bottom line but also its people, both those people responsible for creating the schedules and (in many cases) those whose work is being scheduled. For example, when we were creating an automated scheduler for assigning computer technicians to calls for service [Montana et al., 1998], the technicians were very upset at their loss of autonomy in creating their own schedules. (Their choices were often bad and were causing an inefficiency in the operations.) As another example, the Air Force was motivated to have us build an automated crew scheduler for them because their current approach was leading to unpredictability of schedules, upsetting their people’s family lives and causing high turnover [Rana-Stevens et al., 2000]. An additional effect of implementing an automated scheduler is that it can sometimes require an overhaul of the Information Technology (IT) systems to get the right data to and from the scheduler in a timely manner. This will likely make the IT systems managers unhappy. It is important that the champion(s) have the ammunition required to sell the project. To start, the champion requires a cost-benefit analysis that will justify the project. This should be a realistic analysis because the project will likely be judged against it. Another very useful sales tool is a prototype system that shows the possibility of building the real system and in broad terms how the real system would work. In multiple cases, we have used such a prototype as a means to convince skeptics of the feasibility of automating a process that they previously felt could not be done by a computer. Additionally, one should remember that the selling of the project is a continuous process. Along the way, there should be demonstrations of progress and early releases to get people not doing system development involved in the process. 2 A CONCEPT OF OPERATIONS The concept of operations is how it is envisioned that the system will be used. It is important to develop a concept of operations early in the process because it determines key requirements of the system. Such requirements include: (i) interfaces to data sources and sinks, (ii) schedule turnaround times (which in turn can affect which algorithm to use as discussed below), (iii) user interface functionality, and (iv) automated scheduler logic and functionality. There is a wide range of possibilities for the concept of operations. For example, consider the issue of when to run the automated scheduler and how long it should take to create schedules. This can be as simple as the scheduler making each day’s schedule the night before and printing out the day’s schedule each morning. However, it can also involve dynamic rescheduling, i.e. having the scheduler revise the schedules as they are being executed. For example, a system we built for scheduling computer service technicians needed to create a new schedule every ten minutes. Many of the service calls required attention within a few hours after being received, so to be able to fit these calls in a reasonable manner into the schedules required a fast reaction. A system we built for aircrew scheduling for the U.S. Air Force had the automated scheduler execute only when there were changes that necessitated a new schedule. These changes were either new or modified missions arriving from headquarters or a human scheduler making manual modifications. Another source of variation in the concept of operations is how to involve the human user. It may be as simple as the automated system having the final say with no human scheduling inputs. For our computer service scheduler, the human user needed to be able to override the scheduler in certain situations, because at times the human scheduling agent worked out with the customer certain agreements to which the computer was not privy. For our aircrew scheduler, a human user was required to take responsibility for each assignment. Therefore, we introduced the concept of approval whereby once a human signed off on a particular assignment, there was a cost in the evaluation function for changing that assignment. This cost increased as the time to execute the assigned mission